---
id: index
title: 网络相关
---

import aaa from "../img/http1.jpg";
import http2 from "../img/http2.png";
import http3 from "../img/http协商缓存.png";
import http4 from "../img/Last-Modified.png";

Request Headers

Accept 浏览器可接收的数据格式  
Accept-Encoding 浏览器可接收的压缩算法，如 gzip  
Accept-Languange 浏览器可接收的语言，如 zh-CN  
Connection: keep-alive 一次 TCP 连接重复使用
cookie  
Host  
User-Agent（ 简称 UA）浏览器信息  
content-type 发送数据的格式，如 application/json

Response Headers  
Content-type 返回数据的格式，如 application/json  
Content-length 返回数据的大小，多少字节  
Content-Encoding 返回数据的压缩算法，如 gzip

缓存相关的 headers  
Cache-Control Expires  
Last-Modified If-Modified-Since  
Etag If-None-Match

## HTTP 缓存

HTTP 缓存是指通过在客户端或服务端上存储资源的副本来提高 Web 性能的机制。HTTP 缓存分为浏览器缓存和代理服务器缓存，主要用于降低网络带宽的占用，缩短响应时间。

- 浏览器缓存分为强缓存和协商缓存两种方式:
  - 其中强缓存通过判断缓存的过期时间或者最后修改时间来判断是否使用缓存
  - 协商缓存则通过和服务端进行协商来判断是否使用缓存。

除了浏览器缓存，HTTP 还支持代理服务器缓存，代理服务器缓存能够有效地节约网络带宽，加快响应速度。在 HTTP 请求中使用代理服务器的时候，浏览器会向代理服务器发出请求，代理服务器会将响应结果缓存起来，当下次有相同的请求到达时，代理服务器直接返回缓存中的结果，避免了网络传输的开销。代理服务器缓存使用的是相同的缓存机制，包括强缓存和协商缓存。

在实际的开发中，合理地使用 HTTP 缓存可以极大地提高 Web 应用的性能和用户体验。

### 强制缓存 Cache-Control

强缓存常见的是利用响应头中的 Cache-Control 和 Expires 字段来设置缓存时间和过期时间，  
Response Headers 控制强制缓存的逻辑，例如 Cache-Control:max-age=31536000（单位是秒）

<img src={aaa} />
<img src={http2} />

值：

- max-age
- no-cache
- no-store
- private
- public

:::info
Expires 同在 Response Headers 中，同为控制缓存过期，已被 Cache-Control 代替。
:::

### 协商缓存（对比缓存）

服务器端缓存策略，服务器判断客户端资源，是否和服务端资源一样。一致则返回 304，否则返回 200 和最新的资源

<img src={http3} />
<img src={http4} />

协商缓存则是利用 Response Headers 中的 ETag 和 Last-Modified 字段以及请求头中的 If-None-Match 和 If-Modified-Since 字段来判断资源是否更新。

- Last-Modified 和 Etag
  - 会优先使用 Etag (资源的唯一标识（一个字符串 ，类似人类的指纹）)
  - Last-Modified (资源的最后修改时间)只能精确到秒级
  - 如果资源被重复生成，而内容不变，则 Etag 更精确

## 三种刷新操作方式，对缓存的影响

- 正常操作：地址栏输入 url，跳转链接，前进后退等(强制缓存有效，协商缓存有效)
- 手动刷新：F5 ，点击刷新按钮，石击菜单刷新 (强制缓存失效，协商缓存有效)
- 强制刷新：ctrl + F5 (强制缓存失效，协商缓存失效)

:::tip
刷新操作会影响浏览器缓存的行为。浏览器通常会在发生刷新操作时，强制从服务器重新请求所有的资源，而不是从浏览器缓存中获取资源。这是因为刷新操作会使得浏览器忽略掉所有的强缓存和协商缓存策略，以避免使用旧的缓存资源。因此，即使在使用缓存策略的情况下，如果用户进行了刷新操作，浏览器也会重新请求所有资源。
:::

## TCP 三次握手和四次挥手

TCP 是一种可靠的传输控制协议，它使用三次握手来建立连接和四次挥手来关闭连接。在 TCP 连接中，握手是指在通信开始前的协商过程，挥手则是指在通信结束时的关闭过程。

三次握手：

- 客户端向服务端发送一个 SYN 包，表示客户端请求建立连接。
- 服务端收到 SYN 包后，向客户端发送一个 SYN/ACK 包，表示确认请求并准备好建立连接。
- 客户端收到 SYN/ACK 包后，向服务端发送一个 ACK 包，表示客户端也准备好了连接。

四次挥手：

- 客户端向服务端发送一个 FIN 包，表示客户端没有数据要发送了。
- 服务端收到 FIN 包后，向客户端发送一个 ACK 包，表示服务端已经收到客户端的 FIN 包。
- 服务端向客户端发送一个 FIN 包，表示服务端也没有数据要发送了。
- 客户端收到 FIN 包后，向服务端发送一个 ACK 包，表示客户端已经收到服务端的 FIN 包，然后关闭连接。
- 需要注意的是，TCP 连接的每个方向都需要进行三次握手和四次挥手。

### 每个文件都需要来一遍 tcp 链接吗？

不是的。在 HTTP/1.1 中，会使用持久化连接（persistent connection）来避免每个请求都建立一个 TCP 链接，这样可以显著减少网络负载和请求延迟。持久化连接允许多个请求和响应在同一个 TCP 链接中复用。

在客户端发送完一个请求后，如果服务端响应中包含了 Connection: keep-alive，那么客户端就可以继续在同一个 TCP 连接上发送其他请求，而不需要再次建立 TCP 连接。如果服务器响应中包含了 Connection: close，那么这个 TCP 连接就会被关闭。

## 状态码

| 响应码 |           原因短语            |        描述        |
| :----: | :---------------------------: | :----------------: |
|  1xx   | Informational（信息性状态码） | 接收的请求正在处理 |
| 100 | Continue | 客户端应继续其请求 |
| 101 | Switching Protocols | 服务器已经理解请求，正在切换协议 |
| 2xx | Success（成功状态码）	 | 请求正常处理完毕 |
| 200 | OK | 请求成功，请求所希望的响应头或数据体将随此响应返回 |
| 201 | Created | 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立 |
| 202 | Accepted | 服务器已接受请求，但尚未处理 |
| 203 | Non-Authoritative Information | 服务器已成功处理了请求，但返回的信息可能来自另一来源 |
| 204 | No Content | 服务器成功处理了请求，但没有返回任何内容 |
| 205 | Reset Content | 服务器成功处理了请求，但没有返回任何内容 |
| 206 | Partial Content | 服务器已经成功处理了部分 GET 请求 |
| 3xx |Redirection（重定向状态码） | 需要客户端采取进一步的操作才能完成请求 |
| 300 | Multiple Choices | 服务器可以根据请求来执行多项操作 |
| 301 | Moved Permanently | 请求的网页已永久移动到新位置 |
| 302 | Found | 临时性重定向 |
| 303 | See Other | 请求的资源存在着另一个 URI，客户端应使用 GET 方法获取请求的资源 |
| 304 | Not Modified | 未按预期修改文档 |
| 305 | Use Proxy | 请求应该使用代理访问 |
| 307 | Temporary Redirect | 临时重定向 |
| 4xx | Client Error（客户端错误状态码） | 客户端请求包含错误语法或无法完成请求 |
| 400 | Bad Request | 请求出现错误 |
| 401 | Unauthorized | 客户端未授权该请求 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器拒绝请求 |
| 404 | Not Found | 服务器找不到请求的资源 |
| 405 | Method Not Allowed | 禁用请求中指定的方法 |
| 406 | Not Acceptable | 无法使用请求的内容特性响应请求的网页 |
| 407 | Proxy Authentication Required | 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理 |
| 408 | Request Timeout | 服务器等候请求时发生超时 |
| 409 | Conflict | 服务器在完成请求时发生冲突 |
| 410 | Gone | 如果请求的资源已永久删除，服务器就会返回此响应 |
| 411 | Length Required | 服务器不接受不含有效内容长度标头字段的请求 |
| 412 | Precondition Failed | 服务器未满足请求者在请求中设置的其中一个前提条件 |
| 413 | Payload Too Large | 请求实体过大 |
| 414 | URI Too Long | 请求的 URI 过长 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Range Not Satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足 Expect 的请求标头字段 |
| 500 | Expectation Failed | 服务器内部错误的状态码 |

## http
### http 与https的区别

HTTP（超文本传输协议）和HTTPS（安全超文本传输协议）是用于在客户端和服务器之间传输数据的协议。

HTTP是一种不加密的协议，数据在传输过程中是明文的，容易被黑客窃取和篡改。而HTTPS使用了SSL（安全套接字层）或TLS（传输层安全）协议对传输的数据进行加密和解密，确保数据的机密性和完整性。

具体来说，HTTPS通过使用数字证书来验证服务器的身份，并建立安全的连接。客户端和服务器之间的通信将在SSL或TLS协议的加密保护下进行，以防止黑客篡改或窃取传输的数据。

因此，与HTTP相比，HTTPS更加安全，适用于需要保护敏感数据（如个人身份信息、账户密码等）的网站，例如银行、电子商务等。


### http各版本的区别
- HTTP/1.0：是最早的HTTP版本，它的特点是每次请求都要建立一个新的TCP连接，请求响应都是以明文方式传输。HTTP/1.0版本没有加入keep-alive机制，每个请求都需要单独建立连接和断开连接，这样造成了较大的性能损失。    
- HTTP/1.1：相对于HTTP/1.0做了一些改进，主要特点是引入了持久连接（keep-alive），也就是TCP连接复用。此外，HTTP/1.1还支持请求分块传输（chunked），可以避免在发送大量数据时等待所有数据加载完毕才返回响应，而是采用分块的方式逐步发送数据。  
- HTTP/2：引入了二进制分帧（Binary Framing）的概念，即将HTTP消息分解为二进制格式的帧，每个帧都有自己的帧头和帧体，可以并行发送多个帧，极大地提高了传输效率。此外，HTTP/2还支持服务端推送（Server Push）技术，可以在客户端请求之前将服务器预测的资源推送给客户端，提高了性能和效率。  
- HTTP/3：是目前最新的HTTP版本，它基于UDP协议而非TCP协议，使用了QUIC协议，从而更加高效地传输数据。HTTP/3采用了TLS1.3加密，同时也支持二进制分帧和服务端推送等HTTP/2的特性。HTTP/3主要的改进在于在保证安全和性能的同时，减少了网络延迟和拥塞的问题。  

### http3 怎么优化网络延迟和拥塞的问题
- 采用了QUIC协议：是一种基于UDP协议的新型传输协议，与TCP协议相比，它具有更低的延迟和更好的拥塞控制能力。通过使用QUIC协议，HTTP/3能够更快地建立连接，并且在网络拥塞时能够更好地控制数据传输速度，从而减少延迟和提高网络吞吐量。
- 支持多路复用：HTTP/3支持多路复用，可以在一个连接上同时传输多个请求和响应，从而减少了网络延迟和提高了吞吐量。与HTTP/2相比，HTTP/3使用了更高效的多路复用算法，能够更好地利用网络带宽。
- 使用0-RTT连接：HTTP/3支持0-RTT（Zero Round Trip Time）连接，可以在建立连接时直接发送数据，从而减少了网络延迟。当客户端和服务器之间已经建立了连接时，客户端可以直接发送请求，而不需要等待服务器的响应。
- 采用了快速恢复机制：HTTP/3采用了快速恢复机制，能够更快地从网络拥塞中恢复，从而避免了网络拥塞对数据传输速度的影响。
综上所述，HTTP/3通过采用QUIC协议、支持多路复用、使用0-RTT连接以及快速恢复机制等方式，能够有效地解决网络延迟和拥塞的问题，从而提高了网络性能和用户体验。


### https 加密原理
- 首先，客户端（通常是浏览器）向服务器发起HTTPS请求。这个请求会通过TCP/IP协议传输，但是请求头中包含的信息会被加密。
- 服务器会向客户端发送一个证书，证书中包含了服务器的公钥和一些其他信息。这个证书通常是由权威的第三方机构（例如CA）颁发的，客户端可以通过这个证书验证服务器的身份。
- 客户端使用服务器的公钥来加密一个随机的对称密钥，并将其发送给服务器。
- 服务器使用自己的私钥来解密这个对称密钥。
- 之后，客户端和服务器之间的通信就可以使用这个对称密钥进行加密和解密了。客户端和服务器会使用这个密钥来加密和解密请求和响应中的数据，从而保证数据的机密性和完整性。
总的来说，HTTPS的加密原理主要依赖于对称加密和公钥加密两种技术，通过使用这些技术，HTTPS协议可以保证数据在传输过程中的安全性。
## TLS/SSL
TLS/SSL（Transport Layer Security/Secure Sockets Layer）是一种常用的加密传输协议，用于在计算机网络中对数据进行加密和认证。

TLS/SSL 协议可以在应用层和传输层之间建立安全的通信通道，确保传输的数据在传输过程中不被窃听、篡改或伪造。它主要通过以下几种方式实现安全传输：

数据加密：TLS/SSL 会对传输的数据进行加密，确保数据在传输过程中不被窃听。
身份认证：TLS/SSL 会对服务器和客户端进行身份认证，以确保通信双方的身份合法。
数据完整性校验：TLS/SSL 会对传输的数据进行完整性校验，以确保数据在传输过程中不被篡改或伪造。
TLS/SSL 协议的实现通常需要使用证书来验证服务器和客户端的身份，并通过数字签名确保证书的真实性和完整性。常见的使用 TLS/SSL 的应用包括网页浏览、电子邮件、文件传输等。

### 区别
TLS（Transport Layer Security）和 SSL（Secure Sockets Layer）都是用于保护网络通信安全的协议，但它们在具体实现和功能上有一些区别。

首先，TLS 是 SSL 的继任者，两者的目的和设计目标基本相同，都是为了保护网络通信安全。不同的是，TLS 是 IETF（Internet Engineering Task Force）组织制定的标准协议，而 SSL 则是由 Netscape 公司开发的专有协议。

其次，在具体实现上，TLS 和 SSL 之间存在一些差异。例如，在握手过程中，TLS 使用了更强的密钥交换算法和加密算法，比 SSL 更加安全；而 SSL 使用了一些已知的安全漏洞和弱点，因此不再被广泛使用。

最后，在名称上，TLS 和 SSL 之间存在一些差异。SSL 的版本号从 2.0 开始，到 3.0；而 TLS 的版本号从 1.0 开始，到 1.3。因此，通常来说，TLS 比 SSL 更加安全，更加现代化，也更加适合用于网络通信的安全保护。

## 手写题：Promise.all 
```js 
function PromiseAll(promises) {
  return new Promise((resolve, reject) => {
    const results = new Array(promises.length);
    let count = 0;

    promises.forEach((promise, index) => {
      Promise.resolve(promise)
        .then((result) => {
          results[index] = result;
          count++;

          if (count === promises.length) {
            resolve(results);
          }
        })
        .catch((error) => {
          reject(error);
        });
    });
  });
}
```
这个函数接受一个 Promise 数组作为参数，并返回一个新的 Promise。在实现中，我们首先创建一个空数组来存储每个 Promise 的结果，并设置一个计数器来记录已经成功处理的 Promise 的数量。然后，我们使用 forEach 循环遍历传入的 Promise 数组，并对每个 Promise 进行解析，将其结果存储到结果数组中。在处理每个 Promise 的过程中，我们还要检查已经成功处理的 Promise 的数量是否等于传入的 Promise 数组的长度，如果是，则说明所有 Promise 都已经处理完毕，我们可以将结果数组作为参数调用 resolve 函数来解决新的 Promise。如果在处理 Promise 的过程中发生了错误，则直接将错误对象传递给 reject 函数来解决新的 Promise。


